home *** CD-ROM | disk | FTP | other *** search
- Frequently Asked Questions (FAQS);faqs.416
-
-
-
- A. How to Pick your Processor
-
- The following information appeared in article <13a29iINN21e@iraul1.ira.uka.de>
- by S_JUFFA@iravcl.ira.uka.de (|S| Norbert Juffa). It gives a good indication
- of the relative speeds in Intel's processor line:
-
- UNIX performance of Intel processors as given in Intel's literature
-
-
- Processor SPECmark SPECint SPECfp Whetstone Dhrystone Linpack Ref Rm
- double p. 2.1 dp MFLOPS
-
- 1) Intel 386/387-33 4.3 6.4 3.3 3290 15888 N/A 1 *+
- 2) Intel 386/387-33 4.1 6.0 N/A 3200 18900 0.4 2 #
- 3) RapidCAD-33 6.6 7.3 6.1 5300 18275 N/A 1 *+
- 4) 486DX-25 8.7 13.3 6.6 5640 32000 1.0 2
- 5) 486DX-33 11.1 17.5 8.2 7200 43000 1.5 3
- 6) 486DX-33 12.1 18.3 9.2 N/A N/A N/A 4
- 7) 486DX-33 14.5 19.0 12.2 12300 43500 1.6 5 &
- 8) 486DX-50 18.2 27.9 13.6 10710 64400 2.5 3
- 9) 486DX2-50 19.2 25.4 15.9 18500 63966 2.3 5 &
- 10)486DX-50 21.9 28.5 18.3 18500 65400 2.4 5 &
- 11)486DX2-66 25.6 34.0 21.2 24700 85470 3.1 5 &
-
- Remarks:
-
- * Whetstone/Dhrystone are 32-bit DOS results
- + SPEC ratios recomputed from SPEC timings (computed wrong in report)
- & note huge increase in SPEC floating point performance over previous results
- due to new experimental FORTRAN compiler
- # machine with AMD 386-40/Cyrix 83D87-40/128 kB cache is estimated by me at:
- 7.7 SPECint, 5.0 SPECfp, 6.1 SPECmark,
- 5600 double prec. Whetstones, 23000 Dhrystones,
- 0.6 Linpack double prec. MFlops
- These estimates based on my own measurements and data from:
- FasMath 83D87 Benchmark Report, Cyrix 1990
- World's Fastest 386 40 MHz Am386(tm)DX Microprocessor Performance Summary,
- AMD 1991
-
- References:
-
- 1) Intel RapidCAD(tm) Engineering CoProcessor Performance Brief. 1992
- 2) i486(tm) Microprocessor Performance Report. 1990.
- Order No. 240734-001
- 3) 50MHz Intel486(tm) DX Microprocessor Performance Brief. 1991.
- Order No. 241120-001
- 4) i486(tm) Microprocessor Business Performance Brief. 1990.
- Order No. 281352-002
- 5) Intel486(tm) DX2 Microprocessor Performance Brief. 1992
- Order No. 241254-001
-
- Configurations:
-
- 1) COMPAQ SystemPro 386/33 MHz, 8 MB memory, AT&T UNIX System V/386 Release 4.0
- Version 2.0
- 2) 64 kB write back cache,
- AT&T UNIX System V Release 3.2CC, MetaWare High C R2.2c,
- SVS FORTRAN V2.8
- 3) COMPAQ SystemPro 386/33 MHz, 8 MB memory, AT&T UNIX System V/386 Release 4.0
- Version 2.0
- 4) 128 kB write-back cache, 12 MB RAM,
- AT&T UNIX System V Release 3.2CC, MetaWare High C R2.2c,
- SVS FORTRAN V2.8
- 5) No 2nd level cache, 16 MB RAM,
- AT&T UNIX System V/386 R3.2, MetaWare High C R2.3p
- SVS FORTRAN V2.8
- 6) ALR PowerCache 33/4e, 128 kB cache, 16 MB RAM
- SCO UNIX System V R3.2.2, MetaWare High C R2.2c/R2.3k,
- SVS FORTRAN V 2.8
- 7) Intel Modular Platform, 256 kB write-back cache, 32 MB RAM,
- AT&T UNIX System V R4.0.4, Metaware High C R2.4b,
- Intel Scheduling FORTRAN 77 Compiler V0.2
- 8) 256 kB write-back cache (82495DX/82490DX), 16 MB RAM,
- AT&T UNIX System V/386 R3.2, MetaWare High C R2.3p
- SVS FORTRAN V2.8
- 9) Intel Modular Platform, 256 kB write-back cache, 32 MB RAM,
- AT&T UNIX System V R4.0.4, Metaware High C R2.4b,
- Intel Scheduling FORTRAN 77 Compiler V0.2
- 10)Intel Modular Platform, 256 kB write-back cache, 32 MB RAM,
- AT&T UNIX System V R4.0.4, Metaware High C R2.4b,
- Intel Scheduling FORTRAN 77 Compiler V0.2
- 11)Intel Modular Platform, 256 kB write-back cache, 32 MB RAM,
- AT&T UNIX System V R4.0.4, Metaware High C R2.4b,
- Intel Scheduling FORTRAN 77 Compiler V0.2
-
- One of Intel's most recent wrinkles is the "clock-doubler" chips. The 50DX2
- runs at 25MHz externally but computes at 50MHz. A 66DX2 (bus speed 33MHz) is
- also shipping, and there are persistent rumors of a clock-doubled 50 in the
- works that would compute at a blistering 100MHz! Intel likes to claim a 70%
- speedup for the doublers over their undoubled brethren. I've expressed
- skepticism about this in previous issues, but the SPECmarks above suggest that
- just this once the marketroids may not be lying -- much. Under UNIX, a 50DX2
- is in fact nearly as fast as a true 50DX. Still, beware of anyone whose
- literature passes off the DX2 qualification in the fine print; they may be
- scamming about other things, too.
-
- Right now you'll pay as much as a $500 premium for a 486/50, as that's
- relatively new technology and demands extra-fast memory to run full-out. Also,
- these processors run really hot (one correspondent described the 50 as a
- "toaster on a chip"). If you go this route, be sure your configuration has an
- extra-heavy-duty cooling fan. Or two. And, for preference, a hefty heat sink.
- Of course, if you do this you'll be ready to drop in the rumored 100DX2 part,
- and blow the doors off all those fancy proprietary-technology workstations.
-
- B. Of Memory In...
-
- Buy lots of RAM, it's the cheapest way to improve real performance on any
- virtual-memory system. At $30-$50 maximum per megabyte it's just plain silly
- to stick with the 2-4mb now standard on most clone configurations. Go to 8,
- you won't regret it; 16 if you're going to use X.
-
- Above 16 is iffy on ISA boxes because the stock USL 4.0.3 kernel may try to do
- DMA from a location the bus can't deal with. Most UNIX vendors have fixed this
- by adding code that forces DMAs to take place from low memory; make absolutely
- sure that includes yours before you load up beyond 16MB. The pc-unix/software
- FAQ posting includes information on which vendors are known to have fixed this
- problem.
-
- Some motherboards have 16 sockets for SIMM memory modules. Some only 8. Some
- take only 1MB mdules, some handle 4MB. These constraints interact in funny
- ways.
-
- You should make sure if you are buying an entry level 2 or 6 MB system with a
- 16-socket motherboard that you will not have to ditch the SIMMs that are
- already installed in order to go to your maximum (if 16 MB is your maximum).
- Some systems only allow you to mix 1M and 4M SIMMs in certain combinations.
- Try not to get any 1M SIMMs in your initial configuration, because you'll
- probably end up turfing them later. That is, buy a 4MB, 8MB, 12 MB or 16MB
- system to start.
-
- Newer ISA designs have a 32 MB upper limit with only 8 sockets, since they can
- take 4Mx9s...however, this means different interleaving (only 2 banks), which
- limits the possible configurations. You don't want to start off with an 8 MB
- configuration, because that's 8 ea 1Mx9's, filling up all the sockets...the
- next upgrade requires replacing 1Mx9 with 4Mx9. You can't even set up 12
- MB!...the first reasonable config (that won't require tossing hardware) is 16
- MB, since that's one bank full of 4Mx9.
-
- Most EISA motherboards have 16 4MB-capable sockets, and this is clearly
- where the market is going.
-
- C. Bus wars
-
- Should you buy 16-bit ISA vs. 32-bit EISA? You'll pay up to a $300 premium
- for the latter. What you get in return is the ability to use things like fast
- 32-bit SCSI controllers and a smoother upward-migration path. On the other
- hand, EISA cards are significantly more expensive. And so far, there isn't
- much support for EISA-specific hardware --- a couple of vendors will drive
- EISA SCSI disk and tape controllers and that's about it (of course those *are*
- the most important bandwidth-eaters). All ISA cards will still work.
-
- Of course, most of what you get from EISA is a performance boost. There are
- two different theories about why EISA is better; both have their adherents.
-
- Theory A: Bandwidth matters
-
- UNIX has always been an I/O-intensive operating system. According to this
- theory, increasing processor speed on clones can leave it spending all its time
- waiting on the limited I/O capacity of the poor old 5.3MB/sec ISA bus. The
- vendors all seem to think this starts at around 33MHz and that if you're buying
- 50MHz it definitely pays to go EISA.
-
- Theory B: Cache is what matters
-
- According to this theory, UNIX never comes even close to saturating the ISA-bus
- bandwidth. EISA boards are faster because the premium vendors can charge for
- them allows the motherboard designer more freedom and a richer parts budget.
- The most important performance effect of this is that EISA boards have larger
- and better-designed caches, increasing the effective memory-access speed.
-
- There's probably some truth to both analyses. If your machine is going to
- spend most of its processor time running X displays and doing other classically
- compute-bound tasks, cache size matters most. On the other hand, benchmarks
- show that the combination of TCP/IP and multi-user disk activity *can* saturate
- ISA, and one can sometimes *see* a fast-processor machine slow down during disk
- accesses...
-
- If you're contemplating any kind of heavy-duty networking, EISA network
- adapters will become rather important. A correspondent tells me he's seen
- benchmarks showing what percentage of bus bandwidth is consumed by various
- cards when flooding an ethernet (i.e. consuming the entire 10Mbit bandwidth of
- a quiet net, as you might be when doing an FTP transfer, for instance). 8-bit
- ISA cards consume 40-60% of bus bandwidth; 16-bit cards, 20-40%. 32-bit EISA
- cards consume only about 5-10%. This would be particularly important in a
- machine being used as a bridge, where you might be handling a large portion of
- the traffic on two or more separate nets. The advantage of EISA cards may be
- due to their shorter-cycle bus mastering DMA. At time of writing, only
- SCO supports these, but other UNIX vendors are known to have their own drivers
- in the pipeline.
-
- D. IDE vs. SCSI (vs. ESDI!)
-
- Another basic decision is IDE vs. SCSI. Either kind of disk costs about the
- same, but the premium for a SCSI card varies all over the lot, partly because
- of price differences between ISA and EISA SCSI cards and especially because
- many motherboard vendors bundle an IDE chip right on the system board. SCSI
- gives you better speed and throughput and loads the processor less, a win for
- larger disks and an especially significant consideration in a multi-user
- environment; also it's more expandable.
-
- Another important win for SCSI is that it handles multiple devices much more
- efficiently. If you have two IDE (or ST506 or ESDI) drives, only one can
- transfer between memory and disk at once. In fact, you have to program them at
- such a low level, one drive might actually be blocked from *seeking* while
- you're talking to the other drive. SCSI drives are mostly autonomous and can
- do everything at once; and current SCSI drives are not quite fast enough to
- flood more than 1/2 the SCSI bus bandwidth, so you can have at least two drives
- on a single bus pumping full speed without using it up. In reality, you don't
- keep drives running full speed all the time, so you should be able to have 3-4
- drives on a bus before you really start feeling bandwidth crunch.
-
- All this having been said, don't write off IDE too quickly. Sure, it's
- compatible with the nasty old ST506 interface, but it's *much* faster. It
- remains the cost-effective choice for smaller drives (up to 500MB) on systems
- that won't be hitting the disk constantly. Unless you're running a heavily
- used network or database server, don't assume SCSI will make any noticeable
- difference.
-
- One savvy netter observes "Don't discount ESDI, which is making a comeback.
- At least with ESDI the system knows what the tracks and sectors are -- the OS
- should know this to do good seek optimization." He goes on to observe that
- some ESDI drives are actually faster than SCSI. ESDI hardware is cheaper, too.
- Our editorial opinion is that this is probably a good idea if you're sure
- you're *never* going to want a tape drive --- the SCSI/ESDI price difference
- will get eathen if you have to buy a separate tape controller.
-
- (If you can do your own installation, I hear that used 150/250MB SCSI drives
- are getting quite common and cheap on the net. All 150MB QIC type drives can
- do 250MB on extended-length tapes, though some manufacturers discourage you
- from doing this to avoid excessive heade wear. But back to disks...)
-
- The following, by Ashok Singhal <ashoks@duckjibe.eng.sun.com> of Sun
- Microsystems, is a valiant attempt to demystify SCSI terminology.
-
- The terms "SCSI" and "SCSI-2" refer to two different specifications.
- Each specification has a number of options. Many of these options are
- *independent* of each other. I like to think of the main options (there are
- others that I'll skip over because I don't know enough about them to talk
- about them on the net) by classifying them into five categories:
-
- 1. Logical
- This refers to the commands that the controllers understand.
- SCSI-2 defined a common cammand set that is pretty much a
- superset of the SCSI command set.
-
- 2. Data Width
- 8 bits (+ 1 parity) -> "normal"
- 16-bits (+ 2 parity) -> "wide"
- 32-bits (+ 4 parity) -> I don't know, "extra-wide??"
-
- All three options are available in SCSI-2 (yes,
- the draft spec I have even shows 32-bits!), although
- 8-bit wide is still by far the most common. Not sure, but I believe
- SCSI defined only 8-bit wide data path.
-
- 3. Electrical Interface
- single-ended (max cable length 6 meters)
- differential (max cable length 25 meters)
-
- Both options are available for SCSI-2 (I'm not sure about SCSI,
- but I think both options were available also)
- and this option is independent of options 2, 4, 5. Differential
- is less common but allows better noise immunity and longer
- cables.
-
- 4. Handshake
- Asynchronous (requests and acks alternate)
- Synchronous (multiple requests can be outstanding)
-
- Both options are available for SCSI-2 (Not sure about SCSI,
- but I think both were available also). This is negotiated
- between each target and initiator; asynchronous and synchronous
- transfers can occur on the same bus. This is independent of
- 2, 3 (Not sure about 1).
-
- 5. Synchronous Speed (does not apply for asynchronous option)
- "Normal" is up to 5 Mtransfers/sec ( = 5MB/s for 8-bit wide, more
- for wider)
- "Fast" is up to 10 Mtransfers/s ( = 10 MB/s for 8-bit wide, more
- for wider)
-
- The fast option is defined only in SCSI-2.
- This options basically defines shorter timing parameters
- such as the assertion period and hold time.
- The parameters of the synchronous transfer are negotiated
- between each target and initiator so different speed transfers
- can occur over the same bus.
-
- E. Other Disk Decisions
-
- Look at seek times and transfer rates for your disk; under UNIX disk speed and
- throughput are so important that a 1-millisecond difference in average seek
- time can be noticeable.
-
- Previous issues said "Disk caching is good, but there can be too much of a
- good thing. Excessively large caches will slow the system because the overhead
- for cache fills swamps the real accesses (this is especially a trap for
- databases and other applications that do non-sequential I/O). More than 100K
- of cache is probably a bad idea for a general-purpose UNIX box; watch out for
- manufacturers who inflate cache size because memory is cheap and they think
- customers will be impressed by big numbers." This may no longer be true on
- current hardware; in particular, most controllers will interrupt a cache-fill
- to fulfill a `real' read request.
-
- In any case, having a large cached hard drive (particularly in the IDEs) often
- does not translate to better performance. For example, Quantum makes a 210Mb
- IDE drive which comes with 256Kb cache. Conner and Maxtor also have 210Mb
- drives, but only with 64Kb caches. The transfer rate on the drives, however,
- show that the Quantum comes in at 890Kb/sec, while the Maxtor and Conner fly
- away at 1200Kb/sec. Clearly, the Conner and Maxtor make much better use of
- their smaller cache.
-
- Many retailers seem to enjoy advertising the "9ms" Quantum 52/80/120/200Mb
- drives. This speed, of course, is bogus. All the quantum drives are at least
- 16ms is average access. The 9ms already includes the cacheing speedup.
-
- However, it may be that *any* hardware disk caching is a lose for UNIX! Scott
- Bennett <bennett@mp.cs.niu.edu> reports a discussion on comp.unix.wizards:
- "nobody found the hardware disk caches to be as effective in terms of
- performance as the file system buffer cache...In many cases, disabling the
- hardware cache improved system performance substantially. The interpretation
- of these results was that the caching algorithm in the kernel was superior to,
- or at least better tuned to UNIX accesses than, the hardware caching
- algorithms."
-
- Thus, if your disk controller allows it, try disabling the cache. Your
- throughput may go up!
-
- F. Souping Up X Performance
-
- One good way to boost your X performance is to invest in a graphics card with a
- dedicated blitter or high-speed local-bus connection, like the ATI series or
- the S3-based Quantum, Wind/X and Orchid Fahrenheit 1280. A number of clone
- vendors offer these accelerator options relatively cheap and can make your X go
- like a banshee; however, stock X doesn't support them yet.
-
- SCO's X server supports the ATI Ultra and Fahrenheit 1280, and third-party
- servers for SVr4 are available from MetroLink (email sales@metrolink.com) or
- SGCS (info@sgcs.com).
-
- Here is a current price list from MetroLink:
-
- Runtime (all servers, standard and contrib clients) : 299.00
- Development (full X11 and Motif 1.1.4 libraries) : 299.00
- Xv - Real-Time Video in an X window (true server : 99.00
- extension)
- Xie - X Imaging Extension : 199.00
-
- And here is the corresponding info from SGCS:
-
- Ref # Description Price
- ----- --------------------------------------------- ------
- ** 1 Full X11R5 binaries licensed for a single CPU 295.00
- ** 3 Enhanced X11R5 source code (note 4) 195.00
- 4 MIT source code of contributed clients (note 5) 50.00
- ** 5 Motif binaries for a single CPU 245.00
- ** 7 X11R5 Documentation Set 150.00
- 8 PHIGS Documentation Set 75.00
-
- ** DISCOUNTS:
- If your choose more than one selection from any of the (**) items above
- you will receive the following discounts: $50 off on 2 selections,
- $75 off on 3 selections, $100 off on 4 selections
-
- In general, the ATI approach (normal bus, dedicated blitter and optimization
- for special functions like character drawing) will speed up text display, text
- scrolling and window resize/move operations a lot, but line-drawing and
- graphics only a little. S3, on the other hand, speeds up high-bandwidth
- graphics drawing a lot but doesn't have as big an advantage for ordinary
- text operations. You pays your money and takes your choice. Benchmarks
- indicate that most non-CAD users are better served by the ATI approach.
-
- However, I am now using SGCS X on an S3 with a 17" monitor on a 486/33DX2 and
- can report that it is quite fast enough to make X pleasant to use, thank you.
- Opaque windows can be dragged like paper. This is *fun*!
-
- If you're feeling *really* flush, plump for a 15", 17" or even 20" monitor.
- The larger size can make a major difference in viewing comfort. Also you'll be
- set for VESA 1280x1024 when everybody gets to supporting that. In the mean
- time, the bigger screen will allow you to use fonts in smaller pixel sizes so
- that your text windows can be larger, giving you a substantial part of the
- benefit you'd get from higher pixel resolutions.
-
- If you can, buy your monitor from someplace that will let you see the same
- monitor (exact same, not the same monitor) that will be on your system.
- There's a *lot* of quality variation even in "premium" monitor brands.
-
- The VESA (Video Electronics Standards Association) standard for local bus video
- connectors is now out. When you buy local-bus motherboards, insist that they
- be VESA-conforming. Be very clear about this and get a commitment from your
- vendor; some unscrupulous operations may still be attempting to unload pre-VESA
- motherboards on unsuspecting customers.
-
- V. Tape Drive Follies
-
- You should have a tape drive for backup, and because most UNIX vendors like to
- distribute their OS on tape. Ideally, your tape backup should be able to image
- your entire disk. Unfortunately, this can get quite expensive for large disks,
- as we'll see below.
-
- There are two major technologies in today's desktop tape drive market; QIC
- (Quarter Inch Cartridge) at the low end and midrange, and DAT (Digital Audio
- Tape) at the high end. The dividing line is about 1GB capacity.
-
- DAT is a new technology; it's not far down its price curve yet, but clearly
- where the future is. DAT drive capacities are quoted in *gigabytes* (that is,
- thousands of megabytes).
-
- Most conventional QIC drives have capacities up to 525 megabytes (a little more
- than half a gig). A few high-end units have 1.35GB capacity. QIC is a mature
- technology, but one plagued by hardware incompatibilities and driver bugs.
- Part of the problem is that, until recently, hard disks were small enough
- relative to a floppy's capacity that demand for high-volume backup technology
- was low in the PC world; QIC vendors tended to be small, insular,
- technology-driven firms relatively uninterested in standardization.
-
- As a result, understanding tape drive specifications is far from trivial.
- Tape drive standards are develeped by Quarter Inch Cartridge Drive Standards,
- Inc. (805-963-3853), a consortium of drive and media vendors. They develop
- standards for controllers, transports, heads, and media. Some of these
- become ANSI standards. We'll discuss the most iomportant ones here.
-
- Common Tape Drive Interfaces:
-
- QIC-02 --- intelligent hardware tape interface
- QIC-36 --- simple hardware tape interface
- QIC-104/11 --- SCSI-1 tape interface
- QIC-121 --- SCSI-2 tape interface
-
- These standards describe the drive controller. QIC-02 is presently by far the
- most common, and QIC-36 nearly obsolete (it was designed at a time when
- on-board intelligence for controllers was much more expensive than now). The
- SCSI standards are only rarely cited by number; usually, QIC-104 and QIC-121
- devices are referred to simply as "SCSI tapes".
-
- Common Recording formats:
-
- QIC-24 --- 9-track 60-Mbyte tape format
- QIC-120 --- 15-track 125-Mbyte tape format
- QIC-150 --- 18-track 150-Mbyte tape format
- QIC-525 --- 26-track 525-Mbyte tape format
-
- These standards describe the drive itself.
-
- Now, in theory, these standards are upward compatible; that is, a QIC-120 drive
- can read a QIC-24 tape, a QIC-150 drive can read both QIC-120s and QIC-24s, and
- so on. There's a potential gotcha here, though, called "media
- incompatibility". Thus, we also need to consider:
-
- Common media:
-
- DC600A --- for QIC-24 and QIC-120 drives
- DC6150 --- for QIC-150 drives
- DC6525 --- for QIC-525 drives
-
- The Wangtek 5150ES (and possibly some other 525-megabyte drives) will,
- according to its documentation, decode QIC-24 --- but it won't read a DC600A
- medium!
-
- So, make sure your tape drive can read the media your OS vendor is going to
- ship on. QIC-24 on DC600As and QIC-150 on DC6150s are very widely used as a
- software distribution format in the UNIX world, and you probably want to make
- sure your drive can read them.
-
- 60/120MB QIC drives are fairly cheap now but larger sizes (typically 150, 250,
- 525 QIC tapes and 1.3gig DAT) are not. DAT drives, in particular, cost more
- than a grand each (however, if you have large drives the up-front cost
- difference can quickly get eaten up by media costs).
-
- One interesting point is that if you've gone SCSI, a 150MB QIC (comparable to
- the drives now popular on Suns) may well be cheaper than older 60MB technology;
- the win is in the controller prices, which have plummeted since QIC-24 was the
- cutting edge.
-
- Tape drives are easy to find and pretty safe to buy through mail order. It's
- also possible to buy reconditioned but warrantied used drives substantially
- cheaper than new. One correspondent recommended Super Technologies of Chino,
- CA (800 322 3999); they'll sell you a rebuilt Wangtek 150 with a 7-month
- warranty and a controller card for $300 and change, or a DAT drive for $800.
-
- Your humble editor has a few battle scars from tape drive integration at this
- point. We recommend the Archive ST525, a fine fast drive that works nicely
- with the Adaptec 1542B, *can* read DC600A/QIC-24, and handles highest-capacity
- QIC-525 tapes. Note however that some versions of its documentation have
- a critical typo in the section on setting SCSI drive IDs; they give the ID
- jumpers as JP3/JP2/JP1 when they are actually JP8/JP7/JP6. If you are in
- any doubt about your drive or manual, call Archive tech support and check.
- Also, it does *not* seem to be able to read QIC-120 tapes as claimed; at least,
- 125MB backup tapes from my old AT&T 6386WGS are unreadable.
-
- VI. Of Mice and Machines
-
- In a previous issue, I claimed that all mice and trackballs are the same for
- compatibility purposes. I was wrong -- seriously wrong. The more I found out,
- the messier the picture gets. The following is an attempt to sort out all the
- confusion. Thanks to Jim McCarthy at Logitech for digging into the matter
- and somewhat alleviating my ignorance.
-
- Mice and trackballs used to be simple; now, thanks to Microsoft, they're
- complicated. In the beginning, there was only the Mouse Systems 3-button
- serial mouse; this reported status to a serial port 30 times a second using a
- 5-byte serial packet encoding now called "C" protocol. The Logitech Series 7
- and 9 mice were Mouse Systems-compatible. All UNIXes that have any mouse
- support at all understand C-protocol serial mice.
-
- Then Microsoft got into the act. They designed a two-button serial mouse which
- reports only deltas in a three-byte packet; that is, it sends changes in button
- status and motion reports only when the mouse is actually moving. This is
- called `M' protocol. Microsoft sold a lot of mice, so Logitech switched from
- `C' to `M' --- but they added a third button, state changes for which show up
- in an optional fourth byte. Thus, `M+' protocol, upward-compatible with
- Microsoft's `M'. Most UNIX vendors add support for M+ mice, but it's wise to
- check.
-
- Bus mice are divided into 8255 and InPort types. These report info
- continuously at 30 or 60 Hz (though InPort mice have an option for reporting
- deltas only), and you get interrupts on events and then have to poll hardware
- ports for details. More on these next issue.
-
- In addition to serial mice and bus mice, there are "keyboard mice". On PS/2s
- there are two identical-looking keyboard ports, labeled (with icons) "mouse" &
- "keyboard". Both are 8 or 9 pin mini-DIN's that look like the regular PC
- keyboard port only smaller. I don't know what logical protocol the keyboard
- mouse speaks. Physically, the connector is eventually connected to the
- keyboard processor (often an 8042). The same keyboard processor that decodes
- the keyboard decodes the mouse. PS/2s have this port, many newer ISA/EISA
- motherboards do as well.
-
- All things considered, UNIX users are probably best off going with a serial
- mouse (most current clone motherbords give you two serial ports, so you can
- dedicate one to this and still have one for the all-important modem). Not only
- are the compatibility issues less daunting, but a serial mouse loads the
- multitasking system less due to interrupt frequency. Beware that most clone
- vendors, being DOS oriented, bundle M-type mice for which UNIX support is
- presently spotty, and they may not work with your X. Ignore the adspeak about
- dpi and pick a mouse/trackball that feels good to your hand.
-
- On the other hand: PS/2 mice deliver quadrature output (raw mouse output that
- all mice speak) straight to the computer. This is also how Atari and Amiga
- mice work. This is quite nice, because it makes the mouse simpler (and
- therefore more reliable), and because you only get interrupts when the mouse is
- actually doing something. This also means that if your PS/2 mouse breaks you
- can get a cheap Atari or Amiga mouse (and they *are* cheaper) to replace it
- without sacrificing mechanical quality (which is the important part).
-
- VII. When, Where and How to Buy
-